home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1995 November
/
EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso
/
earcd
/
program
/
assembly
/
d68k20.lha
/
D68k.dok
< prev
next >
Wrap
Text File
|
1995-06-19
|
20KB
|
526 lines
D68k Version 2.0 von Denis Ahrens 1994 ShareWare
D68k ist ein SEHR schneller FILE-Disassembler für den MC68000
68010,68020,68030,68040, FPU 68881,68882 und die PMMU 68851.
Es werden Symbol-, Extern- und Reloc-Hunks unterstützt.
Man kann mit D68k ALLES disassemblieren was aus Hunks besteht, also
auch Objektfiles und amiga.lib's. Desweiteren kann D68k auch
Bootblöcke und Kickstartfiles disassemblieren die als File
abgespeichert wurden.
Die Funktionstabellen innerhalb von Librarys werden unterstützt.
***************************************************************************
SCHNELLSTART
Er wird über das CLI gestartet mit Angabe des Files das
Ihr disassemblieren wollt.
Man kann die Ausgabe mit Control-C jederzeit abbrechen.
Falls die Ausgabe im CLI-Fenster 'läuft', kann man mit einem
Tastendruck die Ausgabe anhalten und mit einem Druck auf die
Backspace-Taste fortsetzen.
z.B.:
1> D68k ram:Prgs/exep04
würde so aussehen:
-------------------------------------------------------------------
01:D68k V1.xx MC68000-68040,MC68881/82,MC68851 Disassembler
02:Copyright DD.MM.95 by Denis Ahrens
03:
04:00000001 00288E20 00000040 00000004 00391828 00000000 00000000
05:
06: CODE ;000 000004
07:
08:000000 4AFC ILLEGAL
09:000002 4E71 NOP
10:
11: ;Hunk-END
-------------------------------------------------------------------
Die Zeilennummern am Anfang gehören natürlich NICHT dazu!
In der vierten Zeile sind StatusInformationen die NUR für mich
sind (zum debuggen).
Für Interessierte:
1. Langwort: Anzahl der Hunks (Nicht der Wert aus dem HUNK-HEADER!!)
2. Langwort: SpeicherAdresse der Hunktabelle
3. Langwort: Größe der Hunktabelle (Hunks * 64 Bytes)
4. Langwort: Länge aller CODE, DATA und BBS Hunks zusammen
5. Langwort: SpeicherAdresse der LabelTabellen
6. Langwort: Anzahl der gefundenen Labels
7. Langwort: Anzahl der sortierten Labels
In der sechsten Zeile steht der HunkName (CODE) mit der Nr. (0)
und der Länge in Bytes (#4).
In der achten und neunten Zeile steht (endlich) der PC
des Hunks, der MaschinenCode und am Ende das (der,die) Mnemonic.
In der elften Zeile kommt dann die EndHunk-kennung.
***************************************************************************
DIE AUSGABE
Bei RELOCxx-Hunks (Reloc32,16,08) wird die Anzahl der zu
korrigierenden Adressen angezeigt. Das ist praktisch zum Optimieren
eigener Programme. Wenn man mit relativer Adressierung arbeitet,
erkennt man so schnell, ob man eine Zeile ohne relativ-code
geschrieben hat.
Bei SYMBOL-Hunks die Anzahl der Symbole.
Bei UNIT- und NAME-Hunks werden die Namen angezeigt.
Bei EXTERN-Hunks werden die Inhalte der Typen <$80 angezeigt.
Wenn D68k einen Bootblock erkennt wird anstelle des Hunk-Namens das
Wort BOOTBLOCK ausgegeben. Die CODE-Größe ist auf 1024 Bytes minus
3 Langwörter beschränkt. (FileSystem-Kennung,Checksumme und
Rootblock)
Um den Code mit A68k zu Re-Assemblieren muß man am Ende des
'Textes' ein " END" anfügen.
Eventuell muß man den Code noch an seinen persönlichen
Assembler anpassen (Ich hoffe nicht).
***************************************************************************
EINIGE ERKLÄRUNGEN
Wenn D68k einen Befehl NICHT erkennen kann, (und er kennt ALLE
Befehle) oder ein Befehl eine NICHT zulässige Adressierungsart hat,
wird er NICHT angezeigt (z.B. JMP D0 oder JSR (A0)+ ). Stattdessen
wird ein Word als Hexzahl ausgegeben.
Bei Befehlen mit Byte-Konstanten, bei denen das high-order-byte
NICHT NULL ist, wird auch das als illegaler Befehl interpretiert.
Da aber manche Assembler/Compiler das Byte per EXT.W zum Wort
erweitern (was FALSCH ist), wird bei negativen Bytewerten der Wert
$ff im high-order-byte eingetragen. Dies wird von D68k
berücksichtigt. Das high-order-byte muss also $00 oder $ff sein.
***************************************************************************
Die NORMALE Methode (TRACE ist NICHT eingeschaltet)
Der Nachteil liegt darin das bei der 'normalen' Methode nach einem
RTS zum Beispiel der Text 'topaz.font',0 auch disassembliert würde.
Dadurch entstehen wirre Befehle, weil sich Datas und Befehle oft
nicht unterscheiden lassen. Unglücklicherweise liegen die kleinen
Buchstaben als ASCII-Code bei $60-70, und genau dort sind die
ganzen BRANCH- und MOVEQ-Befehle. Durch die BRANCH Befehle werden
Fehl-Labels erzeugt und dadurch wird die Ausgabe undurchschaubar.
In manchen Disassemblern werden NICHT angesprunge Befehle im Code-
Hunk als Data-Zeilen angezeigt. Da dies nicht immer klappt, geht
das NICHT mit D68k. Bei der 'normalen' Methode werden im CODE-Hunk
NUR Datas angezeigt wenn KEIN Befehl erkannt wird. Wenn ein
Programm nur MC68000 Befehle enthält und Daten oder Texte von D68k
als MC68010 Befehle (oder höher) erkannt werden, klappt das
natürlich nicht. Aber meiner Meinung nach haben Daten in Code-Hunks
nichts zu suchen.
Falls D68k Librarynamen im Code-Hunk erkennt, werden diese
umgangen. In PASS1 wird die Länge des Library-Textes übersprungen
und in PASS2 wird auf Daten-Ausgabe umgeschaltet. Folgende
Libraries werden unterstützt falls sie an einer geraden Adresse
beginnen:
68040.library dos.library
icon.library intuition.library
expansion.library utility.library
gadtools.library graphics.library
iffparse.library workbench.library
asl.library locale.library
bullet.library commodities.library
diskfont.library exec.library
.library .device
***************************************************************************
DIE TRACE-Methode !!!!!!!!!!!!!!!!!!!!!!!!
Der Unterschied zur normalen Methode ist der, das D68k im ersten
PASS nicht einfach geradeaus durchdisassembliert, sondern bei einem
UNBEDINGTEM Sprung (BRA.x, JMP.x, RTS oder RTx) anhält und sich
eine neue Adresse holt, die vorher vermerkt wurde, und dort weiter
disassembliert u.s.w. Alle so abgearbeiteten Adressen werden als
Befehle markiert.
Falls ein Programm aber eine Adresse mit dem Befehl LEA in das
Adressregister A2 'ladet', und dann per JSR A2 verzweigt kann die
TRACE-Methode das nicht nachvollziehen. Die Befehle werden dann
nicht markiert und werden deshalb im zweiten PASS als Datas
ausgegeben weil D68k diese NICHT als CODE vermerkt hat. Um diesen
Umstand auszugleichen besteht die Möglichkeit, ein Text-File
anzulegen das eine Tabelle enthält, in der die Adresse(n) steht,
die mit dem LEA-Befehl nach A2 geladen wurde. D68k kann dann per
Option das File einlesen, und die Adresse in die interne
SprungTabelle eintragen, um auch diese, vorher nicht erkannten
Befehls-abschnitte disassemblieren zu können.
BEISPIEL:
Man disassembliert den LIST Befehl folgendermaßen:
1> D68K "c:Loadwb" TO "ram:loadwb.asm" TRACE RLO
dann betrachet man das Ergebnis mit einem Editor und sucht
Data-Stellen die nach Befehlen aussehen. (Z.B. kurz vor dem
nächsten Label steht der Wert $4E75, der dem Befehl RTS entspricht)
Im T: Verzeichnis sollte jetzt ein File mit dem Namen
'JumpList.Loadwb' abgespeichert worden sein. Ladet dieses File mit
einem zweiten Editor ein. Die Adressen die Ihr im letzten Schritt
gefunden habt könnt Ihr nun am ENDE dieses Files eintragen.
D68k interessieren nur zwei Hex-Zahlen pro Zeile die mit einem
Komma getrennt sind und mit einem Dollarzeichen ($) beginnen. Das
HexZahlenpaar muß (noch) am Anfang der Zeile stehen. Mann kann auch
ein Semikolon benutzen um Werte zu Testzwecken auszuklammern.
Als erste Zahl muß die HunkNummer, und als zweite Zahl die Adresse
eingetragen werden. Die Hunknummer steht immer am Anfang des Hunks
(an Adresse Null) im Dezimalformat. Ihr müsst also die Zahl noch
umwandeln.
________________________________________________
;
; D68k V1.93 JumpList for 'Loadwb' V38.9
;
$00015455,$00000470 ;Die File-Identifikation und File-Größe
$00,$00035E ;hier kann man Bemerkungen eintragen
$00,$0003B4
________________________________________________
Die Versionsnummer solltet Ihr auch eintragen. Dann kommt Ihr nicht
durcheinandner, wenn Ihr vom dem Programm eine neue Version
erhaltet. Wenn D68k eure JumpList nicht akzeptiert, dann stimmt die
Fileidentifikation in dem JumpList-File NICHT mit dem eingeladenen
File überein.
Speichert das File unter dem Namen 'JumpList.Loadwb' in diesem
Verzeichnis ab:
!!! D68k_JumpLists/
Jetzt gebt folgende Zeile ein:
(Editor im hintergrund laufen lassen)
1> D68k "C:Loadwb" to "ram:Loadwb.asm" TRACE RLO JUMPLIST
Nun könnt Ihr wieder zum Editor umschalten und das File
"Loadwb.asm" nocheinmal einladen. Die vorher nicht erkannten
Befehle sind nun ordentlich disassembliert. Falls noch weitere
Befehls-abschnitte NICHT disassembliert wurden, könnt Ihr weitere
Adressen in dem JumpList-File eintragen und die letzten Schritte
wiederholen.
Meistens genügt es, wenn man eine Adresse einträgt, denn hierdurch
werden meist weitere Adressen vermerkt, wodurch ev. eine Ketten-
reaktion entsteht.
------------------------
Wer es eilig hat, kann die fertigen JumpListen aus dem Archiv
in das D68k_JumpLists/ Verzeichnis kopieren. Wenn Ihr die gleichen
Versionen der dortigen Programme 'besitzt', könnt Ihr diese gleich
benutzen, da ich die Adressen schon eingetragen habe.
Nochmal der vollständige Pfad der JumpListen:
"D68K_JumpLists/JumpList.Loadwb"
!! Wobei "D68k_JumpLists/" in der "homedirectory" von D68k sein muss!.
------------------------
Es gibt zwei Methoden von NICHT erkannten Sprung-Adressen, einmal
mit Label und einmal ohne Label.
1.
Falls die von euch als Befehle identifizierte Routine ein Label
hat, kann man das File "Loadwb.asm" nach diesem Label absuchen (mit
der Editor-Suchroutine) und den weiteren gebrauch der Adresse
verfolgen. So stellt man sicher das es sich wirklich um eine
Befehls-Routine handelt.
2.
Wenn der Routine kein Label vorangestellt ist, dann solltet Ihr das
File "Loadwb.asm" nach JSR's und JMP's durchsuchen. Wenn ein
solcher Befehl relativ springt (z.B. JSR (A0) oder JMP 0(PC,D0.l)
dann solltet Ihr verfolgen wie das Ziel des Sprunges errechnet
wird. Falls kein Sprung zu dieser Adresse zu finden ist, handelt es
sich vielleicht um eine 'tote' Routine die NICHT angesprungen wird.
Wenn Ihr euch ABSOLUT sicher seid, könnt Ihr diese Routine
entfernen.
DIE TRACE-LOGIC (1)
Um die TRACE-Methode noch sicherer zu machen, werden von D68k
auch SprungTabellen erkannt die per JMP L000012(PC,D0.W) springen.
Diese Tabellen sehen so aus, wenn sie von D68k als solche erkannt
wurden:
...CMPI.W #$0014,D1 ;Anzahl der Einträge
BGE.W L000016 ;Bei Überlauf verzweigen...
ADD.W D1,D1 ;Verdoppelung (wegen Wortgröße)
MOVE.W L00000F(PC,D1.W),D1 ;relative Distanz holen
JMP L000010(PC,D1.W) ;und springen
L00000F:
dc.w L000011-L000010 ;hier stehen die Differenzen
L000010: ;vom DIESEM Label aus
dc.w L000011-L000010 ;bis zum Sprungziel.
dc.w L000012-L000010
dc.w L000013-L000010
dc.w L000014-L000010
dc.w L000015-L000010
u.s.w....
Da diese Sprungtabellen sehr verschieden programmiert werden,
ist es sehr schwierig alle Möglichkeiten abzudeken.
Da die TRACE-Methode sehr gut ist, wird die DATALOGIC übergangen.
Auch die RTSLOGIC sollte ausgeschaltet werden. D68k sucht auch
nicht mehr nach Libraries, wie bei der normalen Methode.
***************************************************************************
DIE OPTIONEN VON D68k:
? Listet alle Optionen auf
FILE: Als erstes wird natürlich der Filename des zu
disassemblierenden Files angegeben.
TO/K: Mit dieser Option kann man die Ausgabe in ein File umlenken
Das Intro und die INFO's werden NICHT mit ausgegeben.
Dafür wird zusätzlich der VERSIONS-String ausgegeben, der
Name des Files und die Länge in Bytes.
NOPC/S: Dies MUSS angegeben werden wenn man re-assemblieren möchte.
Hierdurch werden der PC und die HEX-Codes weggelassen.
Das spart eine Menge an Zeit, und das ev. erstellte File
ist wesentlich kürzer.
INFO/S: Es werden ein paar Informationen zu dem File angezeigt
(FileSize, HunkAnzahl, Labels ...).
Die Informationen erscheinen nur im Ausgabefenster, das ist
nützlich wenn man die Ausgabe in ein File umlenkt und
trotzdem ein paar Informationen sehen will.
HUNKLAB/S:
Es werden die Label-Adressen von Symbol-Hunks aufgelistet.
Die Offets von EXT-Hunks werden angezeigt.
(Aber nur die des Typs < $80)
PROBIER DAS zum testen der Option: D68k LIB:amiga.lib hunklab
(Das ist praktisch um die neuen Offsets aus einer NEUEN
amiga.lib zu ziehen, falls man sie hat.)
NC=NOCODE/S
Die Ausgabe der Befehle wird unterdrückt. Das ist praktisch
wenn man NUR die DATA-Ausgabe sehen will, dann braucht man
nicht mehr ewig-lange CODE-Zeilen scrollen lassen.
ND=NODATA/S
Die Ausgabe des Inhaltes aller Daten-Hunks wird unterdrückt.
NB=NOBSS/S
Die Ausgabe aller BSS-Hunk Anweisungen wird unterdrückt.
68020/S Es werden auch Befehle (und Adressierungsarten) disassembliert
die einen MC68020 oder höher benötigen. Durch WEGLASSEN
dieser Option spart man eine Menge an Zeit, und es wird auch
nicht mehr soviel "fehlinterpretiert", denn meistens
sind es ja sowieso nur 68000'er Programme.
HEXDATA/S
Mit dieser Option werden die Daten zusätzlich zu ASCII-
format im Hexformat angezeigt.
------------------------------------
Die TRACE-Methode und ihre Optionen
TRACE/S
Mit dieser Option wird eine alternative Methode benutzt
um Labels und Datas in Code-Hunks zu erkennen. Es werden
alle Sprungmarken notiert bis ein UNBEDINGTER Sprung kommt.
Dann wird eine von den notierten Sprungmarken geholt und an
dieser Stelle wird weiter disassembliert.
Vorteil : Es wird NIE in Datas disassembliert.
Nachteil: Falls per JSR (A0) gesprungen wird, kann diese Adresse
nicht notiert werden und demzufolge fällt dieser
Programmabschnitt (und dadurch ev. weitere) weg.
JL=JUMPLIST/S
Mit dieser Option (nur zusammen mit TRACE) kann man bestimmen
das D68k sich 'notierte' Adressen aus einem File zieht. Dieses
File MUSS im Verzeichnis D68k_JumpLists zu finden sein.
Der Name fängt mit "JumpList." an und endet mit dem Filenamen
den man zum disassemblieren angegeben hat.
In diesem Text-File können von Ihnen eingetragene Adressen
stehen, die D68k sich als abzuarbeitende Sprungmarken merkt.
Dieses gleicht den Nachteil der TRACE-Methode vollständig aus.
------------------------------------
Die folgenden Routinen sind nur für die 'normale' Methode
sinnvoll.
RLO=RTSLOGICOFF/S:
Wenn nach einem RTS Befehl kein Label folgt ist es ziemlich
unwahrscheinlich das Code folgt. Deshalb werden automatisch
nachfolgende Programmdaten als Hex-Datas ausgegeben.
Mit dieser Option kann diese automatische Unterdrückung der
Befehle hinter einem RTS Befehl abgeschaltet werden.
(Das gleiche gilt für die Befehle: BRA, JMP, RTD, RTE, RTM, RTR)
(Sollte bei TRACE-Methode benutzt werden)
DLO=DATALOGICOFF/S
Bei D68k werden NICHT erkannte Hex-Codes als Datas ausgegeben.
Weil der PC an diesen Hex-Codes sowieso nicht vorbeikommt,
können alle nachfolgenden Hex-Codes bis zum nächsten Label
auch als Datas ausgegeben werden. Mit dieser Option kann man
diese Logik abschalten und nur WIRKLICH nicht erkannte Hex-Codes
werden als Datas angezeigt.
(Schaltet die 'RTSLOGIC' auch mit aus)
OLO=ORILOGIC/S
Bei ORI.x Befehlen die aus zwei Wörtern bestehen und ein
Label zwischen den beiden Wörtern ist, wird ein Wort als
Data ausgegeben und die Befehlsausgabe mit dem Label
fortgesetzt. (Wenn nach einem RTS ein 'LeerWort' folgt um
die Routine durch vier teilbar zu machen, denkt D68k das das
ein ORI-Befehl ist. Mit dieser Option kann man diese Befehle
aussschalten.)
------------------------------------
Die folgende Routine ist nur zum Debuggen von D68k.
NL=NEXTLABEL/S
Mit dieser Option wird die Längendistanz bis zum nächsten Label
oder Symbol angezeigt (direkt vor dem PC). Wenn die NOPC-
Option benutzt wird, fällt diese automatisch weg.
(Ist eigentlich mehr für MICH zum debuggen).
*******************************************************************************
WARUM ICH D68K GESCHRIEBEN HABE:
Ich bin neugierig und der DisAsm 1.05 war mir
1. zu langsam
und außerdem
2. benutzt er tausende von SPACE's (ich nehm' TAB's)
3. er spinnt bei OS V36 und höher
4. zeigt zuwenig Nebeninformationen
5. ist er nicht anpassbar (an meine Wünsche)
6. erkennt keine 68020.. Befehle
7. Kreuzberger Nächte sind lang.
Die anderen Disassembler sind entweder zu langsam, haben keine
vernünftige Ausgabe oder kennen keine 68020.. Befehle.
*******************************************************************************
WAS VERBRAUCHT D68K AN SPEICHER?
1. Die eigene Länge
2. Die Größe des zu disassemblierenden Files
3. 128kB für die Labels
4. Pro Hunk werden einmal 64 Byte (genauer Wert in der Status-Zeile
3.LW) und nochmal 1024 Byte belegt (Nur bei Code-Hunks!).
5. Falls die Trace-Option eingeschaltet ist nochmal ein sechszehntel
der Code-Hunklängen. (Pro Wort ein Bit)
6. Falls die Trace-Option eingeschaltet ist 32kB für die Sprungmarken.
7. Falls eine JumpList eingeladen wird, wird dieser Speicher nur
kurzzeitig belegt.
8. Falls die Ausgabe per Option umgelenkt wurde wird ein Buffer von
64KB belegt (SetVBuf()). Dieses aber nur unter OS V39.
*******************************************************************************
FEHLER:
Zeigt aus optischen Gründen keine Labels an ungeraden Adressen
im CODE-Hunk an (da dürften aber auch gar keine sein).
(teilweise behoben: Wenn Daten angezeigt werden, erscheinen auch
Labels an ungeraden Stellen)
Erkennt bisher nur Librarys wenn sie mit ".library" enden, wobei
es case-sensitive ist.
*******************************************************************************
D68k ist vollständig in MC68000 Assembler geschrieben, und
läuft nur mit OS V2.x oder höher ( dos.library >= 37.
Der Rechner selbst spielt keine Rolle. Schnell muß der
Rechner NICHT sein.
D68k ist auf (m)einem Amiga 1000 mit MC68010 2MB FRAM und 130MB
Seagate AT-BUS HD unter OS2.1 - 3.1 geschrieben worden.
D68k wurde mit A68k 2.71 assembliert und mit bLink gelinkt.
Das File-Datum von D68k muß mit dem im Programm übereinstimmen.
Der Source-Code umfasst ca. 13900 Zeilen (260kB).
Es ist inzwischen ein A4000/030 mit einer WD Caviar 700MB und
240MB, 16MB RAM und einem 15" VGA Monitor.
Das Programm D68k ist SHAREWARE. (SWC:01)
Aber es soll jeder selber entscheiden, was Ihm D68k Wert ist!
Für Leute die sich nicht entscheiden können, schlage ich DM 30,- vor.
D68k sollte (darf) nicht benutzt werden um Schutz-Techniken von
Programmen zu entfernen.
Das Programm D68k darf nur ZUSAMMEN mit der Anleitung verbreitet
werden. Die kommerzielle Nutzung und/oder Verbreitung des
Programmes bedarf meiner SCHRIFTLICHEN Erlaubnis. Auch die
Verbreitung in KOMMERZIELLEN (gebührenpflichtigen)
PD-MailBox-Systemen ist NICHT gestattet.
Der Schreiber des Programms übernimmt keine Haftung für materielle
oder geistige Schäden, die durch D68k entstanden sind - entstehen
werden. Das Benutzen des Programmes geschieht auf EIGENE Gefahr!.
Meine Adresse:
EMail: denis@weixi.dialup.fu-berlin.de
SMail: Denis Ahrens
Alte Jakobstr.16
10969 BERLIN
DEUTSCHLAND
Tel: +49-030-614-6127
MODEM: ZyXEL U1496E
BLZ: 100 100 10
KontoNr:2062 61-101
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i
mQCoAi6ktFsAAAEE0gMsJZudB6G7co+Va0MQtLMVcDHOHARCHo7qriFsZ8hvLZef
io7iAlNfdTp9EE9albXYqOIaa4r8dGAzhj3KM/Mvs1qAiiS4vkQfP9lrIMs6Y2/8
yFqcG6gPsWe2EugmprCdEhAhZfuntKCaR8rtmEQJlmKDHdF4+UYGThSBI+ffk1b9
2fzS25/RJO2FWS89KAY13JT8JcP/Ii9RAAUTtBtEZW5pcyBBaHJlbnMgSVJDLU5J
Q0s6IEQ2OEs=
=PVTS
-----END PGP PUBLIC KEY BLOCK-----